The AD Cycle - How it works
Learn about the AD Cycle works for efficient ADAS/AD development
Iterative development practices have proven to be very beneficial, especially in uncertain, complex and volatile fields as we have in AD.
We have created the so called AD Cycle to explain the steps needed to be done in order to create AD functions.
- Design & Develop
- The architectural design of the system and it's components, as well as the design and implementation of the algorithms needed.
- Deploy
- The design is converted into code bindings and configurations to actually bring the application onto the targets ECUs.
- Build
- Creates binary files of the applications as well as the middleware.
- Drive/Measure/Record
- Built binaries are then used during the actual test Drive, which executes the functionality, measures the data generated data, records it and stores it within a mass data storage.
- Replay and Simulate
- Recorded data used to verify and validate the functionality by using re-compute or simulation tooling.
Deployment of the AD Cycle
The AD Cycle can be deployed in two ways:
- as the full cycle including an actual test drive and data acquisition
- as a short cut once data is available
The short cut skips the test drive and re-uses existing data to verify and validate new or adapted functions. In both casas ETAS DMS can reduce the round-trip times dramatically from days to minutes and weeks to hours respectively.
How the ETAS DMS SDK tools support the AD Cycle
The ETAS DMS SDK comprises a set of advanced tools to realize the AD Cycle. The SDK does not "just" care for the individual development steps, but also for the paths between them. These paths make a set of tools an integrated framework.
ETAS DMS provides tooling to design and develop the software architecture - the execution entities, their data connections, and timing requirements.
The tools use a domain specific language called YAAA - which stands for YAml As Architecture - to model the architecture as a set of activities and the triggers that initiate execution (time or data).
As a text-based DSL, YAAA can be created and modified in any text editor but ETAS DMS includes conveniences like editor plugins that make the process easy through features such as syntax highlighting.
As a text-based DSL, YAAA is not only human-readable also are easy to review and to place under change control - in exactly the same way as the project source is managed - through common source control mechanisms.
Finally, ETAS DMS provides a visualizer for YAAA, YAAA-Vis, that enables a graphic overview of the software architecture and enables the use to drill-down into the details of activities and runnables.
"Abstraction from hardware and operating system" are a key determiner of AD/ADAS support. ETAS DMS provides a hardware agnostic development methodology that separates function development from deployment onto the platform.
The ETAS DMS methodology supports both software reuse and, perhaps more importantly, the flexible and scalable deployment of applications to different ETAS DMS middleware instances. As the ETAS DMS Middleware can be deployed to a range of devices such embedded microprocessors for running the applications in the lab, in the test cars, and in production this means the same software can be easily and transparently run wherever it is required.
The primary ETAS DMS tool for deploy and build is YAAAC - the Code & Artefact Generator. YAAAC provides a fully-automated conversion from YAAA design files, i.e the YAML files, to code bindings and configuration files for ETAS DMS Middleware.
YAAAC behaves much like a compiler - only taking as input the YAML design rather than C++ code. As such it's a single step process from user perspective and is highly suited to continuous-integration and development environments.
Finally, ETAS DMS provides a build framework that includes pre-configurated build chain to create middleware runtime and application-level binaries with support for both Linux and QNX targets.
The Drive node of the AD Cycle is the entry point for the ETAS DMS middleware. Here the system as specified in the YAAA model is executed on the deployed target - whether in the lab, on a car or in a simulation.
The ETAS DMS middleware is responsible for the deterministic execution of activities and runnables, for the communication between activities and for supporting data recording and measurement.
There are a number of tools within ETAS DMS that are within "Drive" element of the AD cycle. These tools are collectively known as CARMA (CAR MiddlewAre) and include:
- ADAM provides execution support for runnables within activities and supports distributed triggering based on either data or time
- IPC provides high-performance communication infrastructure for ETAS DMS utilizing a sophisticated zero-copy architecture supporting very high performance (>10GB/s) combined with constant-time communication even as the payload size increases.
- ESME initiates, oversees, and controlles processes such as activities and gateways. As such, ESME plays an important role in orchestrating the interactions between various components.
- HWA provides robust support for hardware accelerators through the Direct Memory Connector (DMC).
- MWALA provides middleware abstraction of business logics. This enables flexible deployment to different middlewares and consequently reuse of business logic implementations.
Re-play / re-compute support and simulation/analysis tools are critical to supporting ETAS DMS virtual drives and the acceleration of the AD development cycle. The "Measure" component within the ETAS DMS middleware enables data recording of all runnable and activity executions in the system including the meta-information on the messages exchanged between the executions.
Recorded information is collected by the ETAS DMS Middleware and can then later to be replayed (using ETAS DMS tooling). Here the recorded data from previous drives is used for the runnables to recompute - rerun - the execution to better understand algorithm behaviour or problems with the algorithm. Recompute support answers the question of how to validate AD open-world problems as now discrete events can be captured on test drives - even if rare - and then used to validate algorithms in the future either manually or as part of a CI validation process.
To record data, ETAS DMS provides the Measurement Gateway (MTA) using a highly efficient direct shared memory access. Measurement Transport Adapter (MTA) supports the systematic data logging of ETAS DMS runnables to enable the deterministc re-compute tools, such as the RecAll Player, to operate.
The recording and storing of measurement data is not a direct part of ETAS DMS as it is HW dependent. ETAS can provide support for storage through a number of mechanisms depending on the bandwidth required, such as the ETAS ETK product family including the ETAS GETK for high-speed data access from the microprocessor.
ETAS DMS support for verification and validation of AD/ADAS systems is where all the previous tools, YAAA & the code generators, CARMA - the ETAS DMS middleware, along with the support for measurement and data recording have been leading to.
First, ETAS DMS includes Robolyzer that provides a graphical introspection tool for system visualization and timing analyzis (visual, timing KPIs) and system visualization including activity and runnable execution, data flow, etc.
Robolyzer includes re-compute support in the form of RecAll Player providing re-Computation of Runnables & Activities.
Second, ETAS DMS includes the Deterministic Open Loop Player, or the the DoL Player for short. This tool enables verification and validation by feeding recorded or simulated data into runnables, (multiple) activities, ECU or complete AD-systems.
The DoL player can be executed on the developer PC, embedded target, or in the cloud. The ETAS DMS DoLPlayer enables virtual releases and the easy deterministic execution of newly developed code from runnable level to complete AD-system for debugging and regression testing. The ETAS DMS DoLPlayer verification can also be integrated into CI/CD systems to provide fast verification.